Vista Permissions And Security Considerations

Developing Applications Using The SoftwareShield System > Deploying Licensed Software > Vista Permissions and Security Considerations

## Vista Permissions and Security Considerations

Windows Vista is an operating system that was designed with security as its primary concern. Due to this, many restrictions was added to Vista that can potentially affect your licensed software.

There are three methods of getting your application to work with Vista.

1. Embed a manifest

2. Manipulate the access control levels of protected resources

3. Install the license and alias files only in the common documents folder and not use virgin registry data at all.

## Using a manifest

By declaring the execution level to requireAdministrator, the application will bring up the UAC elevation prompt whenever it starts up. By elevating the user to administrator, the application will have full access to the registry and every directory. Normally, the registry and certain directories such as program files will be restricted to regular users.

### Embedding a manifest

1. First thing you do is create the manifest file.
   The manifest itself is a XML file and generally looks like this:

<?xml version="1.0" encoding="utf-8" ?>

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

<assemblyIdentity version="1.0.0.0"

processorArchitecture="X86"

name="MyProjectName"

type="win32" />

<description>MyProjectDescription</description>

<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">

<security>

<requestedPrivileges>

<requestedExecutionLevel level="requireAdministrator" />

</requestedPrivileges>

</security>

</trustInfo>

</assembly>

The key information here is the Security tags. Under ”r;requestedExecutionLevel” the level must be ”r;requireAdministrator”.

You must ensure that the following is somewhere in your manifest.

&ldots;

<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">

<security>

<requestedPrivileges>

<requestedExecutionLevel level="requireAdministrator" />

</requestedPrivileges>

</security>

</trustInfo>

&ldots;

2. You would need to make an .rc file. You must have the following in the rc file:
   1 24 "myprojectname.Manifest"
   Replace myprojectname.manifest with whatever you named your manifest.

3. Compile your manifest. The way this would be done is dependant on your programming environment. Normally, your programming environment would have a complier that can compile the manifest into a resource file.

4. Embed your manifest. This would also be programming environment dependent. Some environment would need you to import the resource file. While others may have a manifest tool. It is also possible to inject the manifest into an already existing exe. You would be required to find a method that works for you.

### Checking if you have an embedded manifest

After you embedding your manifest, you can check if it worked properly. Download a tool called CFF explorer. This tool was also recommended by the Windows Certification Program for manifest checking and should be easy to find over the internet.

To check your manifest with CFF explorer:

1. Start CFF explorer

2. Open the main exe of your application with CFF Explorer

3. Click on the Resource Viewer in the tree menu

4. Click on resource 1 (The manifest is most commonly location of the manifest but it may be different depending on your programming language)

5. Look for:

&ldots;

<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">

<security>

<requestedPrivileges>

<requestedExecutionLevel level="requireAdministrator" />

</requestedPrivileges>

</security>

</trustInfo>

&ldots;

Make sure the execution level is ”r;requireAdministrator”

## Manipulating the Access Control Level

As mentioned before, access to the registry and certain directories are restricted. Your installer may modify the Access Control Level (ACL) of the license file, alias file locations, and registry locations because installers normally execute at an elevated priviledge level. The access level of those files, folders and registry keys must be set so "all users" or "everyone" are allowed "full control" to them.

The process of manipulating access level would vary on the Installer you are using. But there will be some common elements between them.

1. Require your program to be installed by an Administrator or configure your installer to perform secured actions using elevated privileges. This is usually required anyway since you will have to register the SSCProt.dll COM server and any other ActiveX controls of your own and this is also controlled under Windows.

2. During installation, manipulate the Access Control List (ACL) for any resources (registry hives, folders) you need during licensing execution to allow all users permission to read and write. This can be done a number of ways. Many installer packages provide integrated ACL manipulation routines that you can use for this purpose. Another popular way to manipulate the ACLs is to use a third party program. A popular (and free) tool to do this during installation is "SetACL - CmdLine". This program can be executed during installation right from your installer on the command line and will quietly set all your necessary permissions. (See: http://setacl.sourceforge.net/)

Remember to set the following files to have read and write access by all users:

- Alias files

- Virgin Registry entry

- Registry alias files

- License files

- Main License File Folder

### Special Notes for Registry alias files

When writing to the registry you must remember to create the key folder and set the permission to Full Control. This is done to avoid virtualization of the alias registry entries.

Also do not use HKEY_CURRENT_USER when using XP. Even if the proper permissions are set, virtualization is unavoidable when using HKEY_CURRENT_USER.

### Special Notes for Windows, System, and Program Files Alias Files

If you use windows, system, or program files folder alias files; you must create a subdirectory and have it set to have full access for all users with your installer.

Under the Alias License Files tab, you can declare the subdirectory with the file name.

Example: Let’s say you are using a windows folder alias file called ”r;tiff10db.tlb”. Instead of ”r;tiff10db.tlb” as your file name, you would name it ”r;<subdirectoryname>\tiff10db.tlb”. When you initiate your license, the alias file will be created under: ”r;C:\windows\<subdirectoryname>\tiff10db.tlb”

The main issue for this is the fact that the license and alias states may differ depending on the user. If the folder that stores alias files is not set to have both write access, Vista virtualizes the file and stores it in the user’s virtual store. This could bring a problem when attempting to corroborate the alias and license file.

More information can be found in the Windows Permission and Security consideration section on manipulating access control.

## Putting files in common documents

The third method would be putting files into the common documents folder. The common documents folder and files within it are set so all users have read and write access by default on vista. This would mean that administrative access would not be necessary for your application to run.

Unfortunately, if you choose this option, you would not be able to use virgin registry entries or any alias files aside from common documents alias files.

During installation, you must put the license file into the common documents folder. When you start your application, it must determine where the common documents folder is, so you can locate your license file.

XP defaults files created in the common document folder to be given write access only to the creator. So if you want your application to work both in XP and vista, you would be required to manipulate the ACL for all files that goes into Vista as in the method described above. If XP support is not needed, then this step is not necessary.